There are various techniques known in the prior art enabling communications between the devices of the Internet and the apparatuses of a private local area network.
First of all, the NAT (Network Address Translator) mechanism of the RFC 3489 standard implemented on an Internet gateway makes the non-routable internal IP addresses of a local LAN correspond to a set of unique and routable external IP addresses. This mechanism can be used especially to make a single public external address visible on the Internet correspond to all the addresses of a private network, and thus mitigate the shortfall of Internet IPv4 addresses. In principle, when the internal address sends out a frame that goes through the router/gateway implementing the NAT mechanism, this address is replaced in the header of the TCP/IP packet by its external IP address. The reverse replacement will be done when a frame whose destination address is this external address is received from the Internet; the external address is then translated into an internal IP address by the Internet gateway.
This mechanism is particular designed in a traditional client/server context of the Internet. Indeed, a major problem arises when a communications protocol (for example UPnP protocol) transmits the source host IP address into the data payload part of the conveyed packet. Since this address is not valid after it has crossed the NAT router, it cannot be used by the destination machine. To overcome this drawback, the NAT routers must inspect the content of the packets that go through them and replace the specified IP addresses by the translated addresses.
However, this implies knowledge of the format of the protocol, and the computation of the checksum and the length of the packet.
Furthermore, this mechanism is very cumbersome in terms of computation load because each packet is analysed and subject to modification. Apart from an increase in the consumption of resources within the NAT router, an increase is observed in the transmission latency of the router.
A more developed mechanism has subsequently appeared. This is the ALG (Application-Level Gateway) mechanism under the RFC 2663 standard similar to a proxy server. Through the principle of inspection of all the packets travelling through the ALG device, this ALG service converts the network information found (IP addresses and TCP/UPD ports) in the data payload part of each packet. It must be noted that this implies that the ALG is given a particular configuration so as to support a precise communications protocol according to a precise version.
For example, the “UPnP remote access” study group has made efforts to define a UPnP architecture having an ALG mechanism of this kind available so as to enable an distant terminal apparatus to get connected to the first local home network and interact with the other UPnP devices of the first local network as if it were physically attached to this first local area network.
Furthermore, this mechanism is very cumbersome in terms of computation load because each packet is analysed and subject to modification.
In the context of a VPN connection between two remote networks such as home networks, the data transferred between these two dwellings is most usually of the audio/video type. Thus, VPN architectures based on the above-mentioned mechanisms can no longer be used to ensure appropriate QoS (Quality of Service) for these audio/video exchanges because the proxy element introduces non-negligible additional latency and jitter into communications travelling through the VPN tunnel.
A HITACHI patent application (US 2007/0127461) entitled “Router and Communications System” proposes a solution that does not use any proxy server between two distinct networks.
The context of this patent application is that of a level 2 tunnel (L2VPN) connecting two remote LANs. Owing to the transparency of the tunnel relative to level 2 protocols (all the level 2 messages are conveyed directly), this patent proposes a method to unify the addressing system between the two connected LANs.
Using a mechanism for distributing information on an allocation of IP addresses for a network and on a filtering of MAC addresses, a master router informs the remote router of the configuration that has to be set up when a tunnel is opened. These pieces of information form part of the message requesting establishment of the tunnel. The pieces of IP address information are used by the remote router to distribute these addresses to the apparatuses of its network. The pieces of MAC (Medium Access Control) address information are used by the remote router to filter the level 2 messages in the case of a multiple-tunnel configuration.
It must be noted that the approach described in the HITACHI patent document (US 2007/012746) partially resolves the problem of conflict of addresses in the context of an L2VPN for apparatuses that have newly started after the setting up of the tunnel. Indeed, in this HITACHI patent document, the router allocates an accurate IP address to the apparatus that has been put into operation. With respect to the DHCP server conflict detection function stipulated by the DHCP standard, the sole advantage of this solution is that it provides a clear separation between the address spaces of each DHCP server.
However, this HITACHI patent document is based on the postulate that every machine of the LAN is off before the tunnel has been set up and will be restarted after the opening of the tunnel. This is not realistic especially in an open-ended context of a VPN connection between non-permanent home networks. Thus, this HITACHI patent document does not propose any solution for managing network apparatuses that are already working when the L2VPN tunnel is set up.
It must also be noted that this HITACHI patent document entails the assumption that the DHCP service and the L2VPN router are implemented by the same machine. The HITACHI patent document is therefore not capable of controlling commercially available DHCP servers.